Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update resource path to be prefixed with resource name #393

Merged
merged 1 commit into from
Jan 17, 2019

Conversation

shashwathi
Copy link
Contributor

Current implementation fetches resources into path /workspace. If task has multiple input resources defined without target path, then resource files can overlap.

With this PR input resources will be places under file path /workspace/task_resource_name . This will provide specific filepath for each resource and there should be no clash as input resources with same names are not allowed.

Note : I have disabled HelmDeployRun e2e test as that requires follow up PR. Test relies on master branch having changes already. It really makes me think there should separate repo with example chart to deploy because we cannot commit change and updated test in same PR.

cc @pivotal-nader-ziada @bobcatfish

@knative-prow-robot knative-prow-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 15, 2019
Why: If task has multiple input resources defined without target path then all
of them would be copied into /workspace folder and would overlap files.

What: With this PR input resources will be placed under file path
`/workspace/task_resource_name` . This will provide specific filepath
for each resource and there should be no clash.
@knative-metrics-robot
Copy link

The following is the coverage report on pkg/.
Say /test pull-knative-build-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/taskrun/resources/pod.go 88.4% 88.5% 0.2

Copy link
Member

@nader-ziada nader-ziada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @shashwathi for the fix 👏

Can we just somehow make the document more clear and add a TODO or a new issue to make the copying of resources to PVC only happen when that resource is needed by a following task

- Copy step includes resource being copied to PVC to path
`/pvc/task_name/resource_name` from `/workspace/random-space/` if resource
is declared in input resource like below example.
- If resource is declared both in input and output for task then copy step includes resource being copied to PVC to path `/pvc/task_name/resource_name` from `/workspace/random-space/` if input resource has custom target directory(`random-space`) declared like the following example.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the different examples here, my understanding is that the resource will be copied to the PVC in the path /pvc/task_name/resource_name in all of the cases, if this is correct why do we need 3 examples?

Copy link
Contributor Author

@shashwathi shashwathi Jan 16, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need all the examples to show that source path when copied to PVC can change depending on

  1. resource only in output
  2. resource in input and output (no target path)
  3. resource in input and output( with target path)

@shashwathi
Copy link
Contributor Author

@pivotal-nader-ziada : #398 for optimization for copy step to PVC

Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM 👼

@knative-prow-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: shashwathi, vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@nader-ziada
Copy link
Member

/lgtm

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 17, 2019
@knative-prow-robot knative-prow-robot merged commit 8557df4 into tektoncd:master Jan 17, 2019
@bobcatfish
Copy link
Collaborator

Thanks for fixing this @shashwathi !

shashwathi pushed a commit to shashwathi/build-pipeline that referenced this pull request Jan 18, 2019
…ame"

- In PR tektoncd#393 resource was placed under path "/workspace/resource_name",
there is a use case where a resource can be used by a task multiple
times as source with duplicate names.
- Add more unit test to have more coverage for this use case.
- Enable helm deploy task in this PR (tektoncd#393 PR disabled it as there is
cyclic dependency)
shashwathi pushed a commit to shashwathi/build-pipeline that referenced this pull request Jan 18, 2019
…ame"

- In PR tektoncd#393 resource was placed under path "/workspace/resource_name",
there is a use case where a resource can be used by a task multiple
times as source with duplicate names.
- update storage resource(gcs) to have new namespace path as well
- Add more unit test to have more coverage for this use case.
- Enable helm deploy task in this PR (tektoncd#393 PR disabled it as there is
cyclic dependency)
knative-prow-robot pushed a commit that referenced this pull request Jan 18, 2019
…ame"

- In PR #393 resource was placed under path "/workspace/resource_name",
there is a use case where a resource can be used by a task multiple
times as source with duplicate names.
- update storage resource(gcs) to have new namespace path as well
- Add more unit test to have more coverage for this use case.
- Enable helm deploy task in this PR (#393 PR disabled it as there is
cyclic dependency)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants